The uses and capabilities of mobile communication devices have rapidly increased in recent years. For example, mobile communication device users now have the capability to make payments using their mobile phone. While mobile payments provide a convenient tool for a consumer, mobile payments may also present security concerns. Sensitive information, such as a consumer's personal information, account information, etc., can be prone to interception. Additionally, if the mobile communication device is lost or stolen, such information can be used by an unauthorized user. Furthermore, as mobile payment applications evolve, there is a need not only to protect information sent from the mobile communication device, but also to protect information sent to the mobile communication device during transmission.
In current mobile transaction environments, a financial institution (such as a bank) related to a payment device typically has its own trusted service manager (TSM) in order to communicate with a secure element (SE) for provisioning an account associated with the payment device on a mobile communication device. The secure element allows the mobile communication device, e.g., to communicate with a near-field communication (NFC) reader being located at merchant locations for conducting contactless transactions.
Conventionally, a consumer or client wishing to provision an account on a mobile communication device needs to have his/her identity verified by the issuer of the account. Thus, the consumer or client contacts the issuer to provide personal information, e. g. a primary account number, a card expiration date, as well as personal identification information such as name, date of birth, etc. Once the issuer verifies that the consumer or client is the approved user of the account, the issuer would send/give an account activation code to the user. The user then provides the account activation code to a payment processing network for provisioning the account on the mobile communication device. The payment processing network contacts the issuer to confirm the account activation code and that the user is already authorized by the issuer. This process is inefficient as it involves unnecessary communication between the payment processing network and the issuer during the provisioning of the account on the mobile communication device.
Hence, it is generally known to use a sequential process in a push-driven model for the provisioning of services in a secure element such as the UICC: The customer orders the service from the service provider. Then the service provider checks the request, sets up the service and orders a trusted service manager to personalize and encrypt the data and manage the installation steps towards the mobile network operator. The mobile network operator checks it and sends the data via the mobile network, e.g. using the BIP (Bearer Independent Protocol)/CAT-TP protocol (Card Application Toolkit Transfer Protocol) to the UICC.
A limitation of this approach is the separation of the order process for a service and the installation of it. The customer often gets no feedback about the success of the installation. Only in the wallet app the customer can see if the installation was successful. Also the BIP/CAT-TP protocol is less stable than a mobile internet connection.